Known push to talk systems exist that allow integration of packetized push to talk functionality with existing circuit switched-based wireless operation. Wireless push to talk mobile devices utilize known commercial cellular systems infrastructure, such as the CDMA-based network that is operated by Verizon Wireless, to support push to talk functionality.
It is known that push to talk functionality on cellular systems is achieved by utilizing the data transport capabilities of the wireless device and related network components of the cellular network, whereby digitized voice is packetized into data packets, such as IP packets, at the wireless device and then transported over various data transport related components of the cellular network. The Session Initiated Protocol (SIP) is typically used in conjunction with a push to talk control server and other relevant data network components, to facilitate push to talk SIP call origination and call maintenance.
Because push to talk connectivity is expected by subscribers to be near instantaneous, wireless push to talk devices generally operate in an “always on” state, whereby the wireless push to talk device remains logged with components of the cellular network that relate to data network functionality. This, in turn, requires that the wireless push to talk device remain registered with the various network components regulating the wireless push to talk device's access to the transport facilities of the cellular network.
Accordingly, a wireless push to talk device first registers, and remains registered, with various network components before it can engage, or be made available to engage, in push to talk conversation. For example, a wireless push to talk device may need to register with a Home Location Register (HLR), an Authentication, Accounting and Authorization server (AAA) and a push to talk control server.
Often times, one or more of the network elements with which registration is required are not available due to any one of various reasons, such as a power outage or software malfunction, thus causing a wireless push to talk device to loose connectivity with the network elements as well as causing it to loose the ability to engage in push to talk activity. Upon loosing connectivity, a wireless push to talk device operating in “always on” mode will immediately attempt to reestablish communications and again register with the network component with which it has lost registration. Upon failure of subsequent registration attempts, the wireless device will continuously make additional attempts to register with the relevant network component until successful. Repeated registration attempts can lead to severe network congestion in situations where hundreds, if not thousands, of wireless push to talk devices are continuously attempting to register with the various network components at the same time. Since, at any given time, only a fraction of push to talk subscribers are attempting to engage in push to talk communications, a continuous attempt by all wireless push to talk devices to register with one or more network components at the same time should be avoided.